Service-level agreements

Platform service-level agreement

This agreement is made between Cumulocity (“Provider”) and the Customer (“Customer”) who utilizes Cumulocity Platform (“Service”) for managing Internet of Things (“IoT”) devices (“IoT devices”, “devices”) on Provider’s cloud instances (“software-as-a-service”, “SaaS”).

Service description

Cumulocity is a comprehensive Internet of Things (IoT) platform designed to enable seamless connectivity, management, analysis and control of IoT devices. This agreement defines the service level of Cumulocity Software-as-a-Service operated by Cumulocity. Cumulocity Edge is outside the scope of this agreement.

The agreement applies solely to the base platform excluding optional features or features not in general availability. Optional features outside the base platform may require a separate service-level agreement. For custom applications developed using the Microservice Hosting functionality, refer to the Microservices hosting service-level agreement.

Service features

The Cumulocity platform offers a comprehensive set of features designed to support the needs of enterprise IoT deployments, ensuring robust performance, security, and flexibility. Key service features include:

• Device connectivity and management: The platform facilitates the connection, data collection, and remote control of IoT devices. These functionalities can be accessed through the Cumulocity Device Management application or via application programming interfaces (APIs; REST/MQTT).
• Data visualization: Users can visualize their connected devices and corresponding data within the Cumulocity Cockpit, offering an intuitive interface for monitoring and managing IoT deployments.
• Real-time and batch data processing and storage: Cumulocity supports both real-time and batch processing of IoT data, enabling users to efficiently manage and analyze large volumes of data as it is generated. Data storage is Customer-configurable, allowing you to define retention periods according to your specific requirements.
• Flexible deployment options:
  • The platform is deployed using shared (“Cumulocity”) or dedicated cloud instances (“Cumulocity Enterprise Dedicated”), tailored to meet the needs of your organization.
  • Optionally, separate environments for pre-production (non-production) activities can be purchased to ensure smooth development and testing processes.
  • Cumulocity is hosted in Customer-selected regions (EMEA, APAC, Japan, and the US).
• Support services:
  • The platform offers tiered product support to meet varying operational needs as outlined in the support agreement.
• Proactive monitoring and management:
  • Cumulocity includes 24x7 platform monitoring, with a publicly accessible status page and real-time status notifications to keep you informed.
  • The platform’s availability, capacity, and performance are actively managed to ensure consistent and reliable operation.
• Information security compliance:
  • We operate the platform in compliance with SOC II and ISO 27001 standards, encompassing a wide range of security measures, including vulnerability management, security incident management, DDoS protection, intrusion detection, and encryption of data both in transit and at rest.
• Business continuity and resilience:
  • Cumulocity adheres to ISO 22301 standards for business continuity management (BCM), ensuring resilience against zone outages with zone redundancy.
  • Regular backups are maintained with a 30-day retention period, a Recovery Time Objective (RTO) of 12 hours, and a Recovery Point Objective (RPO) of 24 hours. Backups are stored in the same region where the service is hosted.
  • Cumulocity conducts regular drills to validate its disaster recovery procedures.
• API compatibility management: The platform maintains compatibility of APIs as outlined in its Compatibility policy. Transport protocols are managed in accordance with this policy, ensuring consistent and reliable API interactions.
• Data ownership and portability: As the data processor, Cumulocity ensures that Customer retains full ownership of their data. Customer can export their data at any time using the provided APIs, ensuring control and flexibility over their information.
• Continuous maintenance and upgrades: The platform undergoes regular maintenance and upgrades to ensure optimal performance and security. These upgrades happen transparently and without involving Customer.

For Customers with legacy service agreements, these features may differ in accordance with the terms of their original agreements.

Customer responsibilities

As a Customer of the Cumulocity platform, we request your acknowledgment of the following responsibilities to ensure the continued security, performance, and efficiency of the service.

Security management

• Device security: While the Cumulocity platform provides robust security measures, Customer is responsible for the security of devices and device credentials. Cumulocity cannot be held liable for any leaked credentials from devices. Customer acknowledges that communication protocols and ciphers may require periodic updates to address evolving security threats. This may necessitate updates to the devices themselves.
• End user access security: To protect the integrity of the cloud platform, Customer is encouraged to educate users on secure usage practices, such as implementing multi-factor authentication. Customer is responsible for managing user credentials, and Cumulocity cannot be held responsible for any compromised credentials.
• Certificate management: Customer is responsible for monitoring the expiration of their certificates. Expired certificates can result in service unavailability for the associated clients, and Customer expressly acknowledges this responsibility.
• Library updates: Customers utilizing Cumulocity-provided libraries to build their own applications are responsible for ensuring these libraries are kept up to date with respect to security. In the event of a security vulnerability or other critical update, it is Customer’s responsibility to implement the necessary updates in their applications to maintain the integrity and security of their systems. Cumulocity cannot be held liable for any security issues arising from outdated libraries in Customer applications.

Capacity management

• Scalability considerations: While the Cumulocity platform is designed to be scalable, it may not be able to accommodate sudden, extreme capacity demands (for example, all devices attempting to connect simultaneously after a connectivity outage, or all devices being upgraded at the same time). Customer acknowledges that such requests may be delayed or declined by the platform to maintain overall service stability. Customer is advised to implement an exponential backoff strategy.
• Soft quotas: Customer acknowledges the existence of “soft quotas” as documented in Service quotas. These quotas are not strictly enforced but exceeding them may lead to a reduced service level, and Customer is advised to operate within these guidelines.
• Data retention management: Data storage is included as part of Customer’s subscription. Customer is responsible for configuring appropriate data retention rules within the Cumulocity Administration application, balancing their specific use case requirements with budgetary considerations.

For details on non-permitted uses of Cumulocity, refer to the Cumulocity Terms of Service.

Limitations and constraints

In the interest of transparency and to ensure a mutual understanding of the service capabilities, we kindly ask Customer to acknowledge the following limitations and constraints of the Cumulocity platform:

• Hard quotas: Customer acknowledges the existence of hard quotas as detailed in Service quotas. These quotas define maximum thresholds that the platform can support and are essential for maintaining overall system stability.
• Shared environment considerations: Customers not utilizing Cumulocity Dedicated plans should be aware that their tenant is hosted within a shared environment. As a result, response times may occasionally vary due to shared resource usage, and Customer acknowledges such variations. Furthermore, infrastructure-level information such as HTTP or MQTT access logs cannot be shared with Customer.
• Data retention and storage costs: Customer acknowledges that reducing data retention periods does not immediately lead to the reclamation of storage space or a reduction in storage costs due to technical processing requirements.
• Distributed IoT system: Customer acknowledges that IoT systems, by nature, are distributed and internet-based:
  • Connectivity reliability: Connectivity may occasionally fail. To ensure reliable communication, Customer devices and clients should implement appropriate reconnect or retry strategies. Singular connection drops or temporary failures are considered normal and do not constitute a service failure. Cumulocity is committed to working with Customer to troubleshoot and resolve consistent and repeating communication issues.
  • Third-party connectivity services: Connectivity may involve third-party services such as LPWAN or mobile network operators. Customer acknowledges that while Cumulocity facilitates the transfer of data through these services, it does not operate, monitor, or troubleshoot these third-party networks. Connectivity between Customer’s devices and Cumulocity service is in the sole responsibility of Customer.
• Data recovery: While Cumulocity maintains backups of data for its own business continuity management, disaster recovery on behalf of Customer (for example, after accidental data deletion by Customer) is a separate service. Customer expressly acknowledges the backup retention period and RPO outline above.

Service availability

Cumulocity is committed to providing reliable service. The specific service availability targets are as follows:

• Production environments: 99.90% availability
• Preproduction environments: 95.00% availability

Service availability for Cumulocity is calculated as follows:

• The platform service consists of the service components “API Services” (REST) and “MQTT Services” as shown on the status page of the respective platform.
• The service components are regularly tested for availability and performance by simulating typical usage.
• The service availability of the service component for a month is the share of minutes the service component is available, excluding planned downtimes and emergency maintenance.
• The overall service availability is the average of the service components.

For non-production instances, the following are also excluded from the availability calculation:

(a) Planned and announced maintenance tasks: These may include, but are not limited to:

• Installation and upgrades of the entire platform.
• Deployment of new components.
• Upgrades to underlying third-party components (for example, Kubernetes, Database systems).

(b) Third-party platform issues: Any issues with the underlying computing platforms (for example, Azure, AWS) that result in service unavailability are excluded from the availability calculations.

(c) Events of force majeure.

The status pages showing the service availability results are at

• status.cumulocity.com for US and EMEA instances.
• cumulocity-apj.statuspage.io for APJ instances.
• a dedicated location for Cumulocity Dedicated instances.

Planned and unplanned downtimes for the services are communicated via the Cumulocity status page, which will also provide an expected time for the system’s return to availability. Please note that the availability of the status page itself is not included in the services availability calculations.

Service credit commitment

Credit calculation

If the service is available for less than the availability outlined above during any full calendar month during the cloud services term, Customer will be eligible for a service credit for the particular service in accordance with the formula below (a “Service Credit”).

For services with 99.90% availability target:

For services with 95.00% availability target:

Credit request

Customer must submit all requests for Service Credits by filing a request (“Service Credit Request”) to support, including the necessary information to evaluate the request, including:

1. the date, time and duration of the incident giving rise to the Service Credit Request (the “Incident”);
2. a detailed description of the incident, including any measures taken by Customer to resolve the issue;
3. the tenant, number of Customer users and location(s) of Customer users affected by the incident (if applicable); and
4. any additional information reasonably requested by Provider necessary to validate the incident.

Provider must receive the Service Credit Request within fourteen (14) days from the occurrence of the incident. Provider will evaluate the Service Credit Request as soon as all information necessary to review the Service Credit Request is received. Provider will use commercially reasonable efforts to process complete Service Credit Requests during the subsequent calendar month and within thirty (30) days of receipt. If the incident is confirmed by Provider and gives rise to a Service Credit, Provider shall provide Customer with a refund within thirty (30) days of Providers determination. The total amount credited to customer in a particular year under this SLA shall not exceed 5% of the annual fee (exclusive of any taxes) paid by the Customer for the affected services.

Requirements and exceptions

Customer must be current on any payment obligations owed to Provider and in compliance with the terms of the Agreement and the order form in order to be eligible to receive Service Credits. The service availability commitments do not apply to any performance or availability issues:

1. Due to acts or conditions outside of Provider’s reasonable control, including, but not limited to, a Force Majeure event as defined in the agreement above;
2. Initiated by Provider to protect the services or Customer data from unauthorized access or loss;
3. Caused by Customer’s use of services, hardware, or software not provided by Provider which affect the availability of the service; or
4. Caused by your use of services other than expressly authorized by, and in accordance with, the terms of the Agreement and the order form or Customer’s use of the services after we advised you to modify your use of the service, if you did not modify your use as advised.

Exclusive remedy

Except as expressly set out in the Agreement, Customer acknowledges and agrees that Provider’s sole obligation and Customer’s exclusive remedy for Provider’s failure to meet the service availability requirements are set forth in this service credit commitment.

Support and maintenance

Support

• Customer support: Support is provided in accordance with Customer’s selected support plan, as detailed in the support agreement.
• Pre-production environments: For pre-production environments, Starter-level support is generally provided, with support tickets handled at standard priority.

Maintenance

• Ongoing maintenance and upgrades: The Cumulocity platform is continuously maintained and upgraded to ensure optimal performance and security.
• Seamless upgrades: This maintenance process is designed to be seamless and generally invisible to Customer. The timing and content of upgrades are at the discretion of Cumulocity.
• Upgrade information: Details about scheduled upgrade times are available on the platform’s status pages as outlined above, while information about the specific changes included in each upgrade can be found in the change logs within the user documentation.
• Regulated environments: For customers operating in regulated environments, an optional annual maintenance schedule is available to meet specific compliance requirements.

Acceptance

By using the Services provided by Cumulocity, Customer agrees to adhere to the terms outlined in this SLA.

Microservice hosting service-level agreement

This agreement is made between Cumulocity (“Provider”) and the Customer (“Customer”) who utilizes Cumulocity Microservices (“Service”, “Container-as-a-Service") for deploying Customer Microservices (“Microservices”) on Cumulocity cloud instances.

Service description

The Provider hosts and manages a Container-as-a-Service cluster based on Kubernetes that allows the Customer to run custom Microservices within their Cumulocity tenants (purchased separately). This Service includes the orchestration of Microservices through Kubernetes, ensuring scalability, high availability, and efficient resource management.

Service features

Cumulocity Microservices includes the following features.

• Microservice management: Cumulocity Microservices provides Customer with the means to deploy, update, run, load-balance and monitor Microservices. Optionally, it automatically
  • Scales Microservices in case of high CPU load.
  • Restarts Microservices in case of unresponsiveness or errors, provided Microservice includes a liveness probe.
• Resource allocation: Cumulocity Microservices ensures that the capacity as declared by the Customer for each Microservice is consistently provided within the limits of this service-level agreement.
• Monitoring and health checks: The Service includes monitoring capabilities that leverage Kubernetes’ system of liveness and readiness probes to maintain the health and performance of Microservices provided the probes are implemented (see below).
• Authentication: The Service ensures that only authenticated users access Microservices.
• Security management: The Service includes the security management of the Cumulocity Microservices infrastructure (excluding Microservices themselves) including security monitoring, software upgrades, network isolation and potentially other measures.
• Subscription management: Cumulocity Microservices lets you subscribe your customers to Microservices.
• Metering and billing: Cumulocity Microservices meters the infrastructure resource usage of the Microservices.

Customer responsibilities

Customer acknowledges the following Customer responsibilities. Customers are encouraged to review the Cumulocity Microservices documentation, particularly the developer’s guides and change logs.

• Microservice development:
  • Liveness and readiness probes: Customer implements suitable liveness and readiness probes that reflect the state of Microservices as outlined in the Kubernetes developer documentation. In case liveness and readiness probes are not implemented, availability service-level requirements do not apply, and outages may occur.
  • Authorization: It is in Customer’s responsibility to verify the authorization of the authenticated user.
  • Software management: Customer manages the software used inside Microservices, including third-party software components and container operating systems. Customer acknowledges their sole responsibility for Microservices’ compliance with applicable laws and regulations, including intellectual property rights, licenses, and other legal requirements. Provider shall have no responsibility or liability for any IPR, licensing, or other legal issues arising from Customer’s use of Microservices.
  • Security management: Customer manages the security inside Microservices, including software vulnerability management and usage of credentials in Microservices. Customer acknowledges their sole responsibility for the vulnerability management of Microservices, including identifying, addressing, and mitigating any security vulnerabilities, breaches or other incidents. Provider shall have no responsibility or liability for any vulnerabilities, breaches, or other security issues related to Microservices.
  • Statelessness: Microservices must be designed stateless. Persistent storage must be handled using Cumulocity APIs or external services. If Microservices are not designed stateless, Customer acknowledges that the state can be lost at any time.
  • Memory: Customer verifies Microservices for memory consumption in line with the configured memory limits. If limits are exceeded, Microservices may be restarted or eventually terminated.
• Microservice configuration:
  • Replicas: Customers are advised to configure at least two replicas of Microservices. In case only one replica is configured, availability service-level agreements do not apply and Microservices outages may occur.
• Microservice operations: While Cumulocity Microservices provides means for resource management and high availability, it is in Customer’s responsibility to monitor and operate Microservices. Cumulocity Microservices will provide information about the runtime state of Microservices (such as log information from Microservices), but it is in Customer’s responsibility to troubleshoot and rectify out-of-memory conditions, crashes, or restarts of Microservices as required by Customer.
• Usage monitoring: Microservices are charged based on parameters such as running number of Microservices instances and defined resource limits. It is the Customer’s responsibility to determine unused or underused Microservices.

Limitations and constraints

Customer acknowledges the following limitations and constraints in using Service.

• Storage: No persistent storage is provided beyond Cumulocity API services. Changes to files inside Microservices are not preserved across restarts.
• Port Restrictions: Microservices are limited to one inbound REST API port. This restriction is crucial for maintaining the security and simplicity of the network architecture.
• Network restrictions: To ensure network security, Microservices can only communicate with the Cumulocity API and externally. Microservices cannot directly communicate among each other. Network connections may be automatically reset at any time and need to be reconnected by the Microservices. Provider reserves the right to stop or remove Microservices with excessive outbound networking traffic.
• Mandatory authentication: To simplify access control, all requests to Microservices are authenticated by Cumulocity prior to reaching Microservices.
• Restarts: Microservices may be automatically restarted or relocated across the cluster at any time to ensure optimal performance and availability, or for the management of the Cumulocity Microservices infrastructure.
• Capacity requests and limits:
  • There is an upper bound on the capacity that can be requested for a Microservice (“requestedResources” in the Microservices manifest). This upper bound is usually 250m of CPU and 256 MB of memory but may vary depending on your Cumulocity instance.
  • Upper bounds for capacity limits (“resources” in the Microservices manifest) may vary based on the Cumulocity instance.
  • Cumulocity may block large capacity requests occurring in a brief period.
  • In case of doubt, please contact product support for bounds and larger capacity requirements (for example, onboarding a single-tenant Microservice with many customers).
• Security and performance management: Provider may stop or remove Microservices in case of a severe security or performance impact to Cumulocity. Customers are expressly prohibited from engaging in any destructive activities on the Cumulocity production infrastructure. This includes penetration testing, performance testing, stress testing, or any other activities that may compromise the integrity, performance, or security of our systems.
• Quotas as documented.

Service availability

Service availability of Cumulocity Microservices follows the general service terms of Cumulocity.

Support and maintenance

• Technical support: The Provider will offer technical support for issues related to the Kubernetes infrastructure and the deployment of Microservices via the Service. Support for developing or debugging Microservices is outside the scope of this service-level agreement but can be requested from Provider Professional Services.
• Maintenance windows: Scheduled maintenance will be communicated in advance through Provider’s status notification system (for example, https://status.cumulocity.com/ for EU, US, EMEA), and efforts will be made to minimize disruption during these periods.

Acceptance

By using the Services provided by Cumulocity, the Customer agrees to adhere to the terms outlined in this SLA.

DataHub service-level agreement

This agreement is made between Cumulocity (“Provider”) and the Customer (“Customer”) who utilizes Cumulocity DataHub (“Service”) for offloading and analyzing Internet of Things (“IoT”) data using Provider’s cloud instances (“software-as-a-service”, “SaaS”).

Service description

Cumulocity DataHub is a component of the Cumulocity platform that enables efficient long-term storage and analysis of IoT data. It offloads data from the operational store to a data lake, allowing for scalable SQL-based querying via standard interfaces like ODBC and JDBC.

This agreement defines the service level of Cumulocity Software-as-a-Service operated by Cumulocity. Cumulocity Edge is outside the scope of this agreement.

Service features

Cumulocity DataHub provides the following features.

• Scalable and economic long-term data storage: Cumulocity DataHub offloads data into economic data lake storage outside of the operational store for long-term data retention, permitting you to shorten the retention times of the more costly operational store.
• Advanced data querying: Long-term data is made available for in-depth analysis to SQL-based analytics tools such as business intelligence, notebook, and dashboarding applications.
• Configurable offloading: So-called “offloading pipelines” permit you to select what data is offloaded and how it is mapped into the data lake for user-friendly, SQL-based querying.

Customer responsibilities

Customers are encouraged to review the Cumulocity DataHub documentation. In particular, Customer acknowledges the following Customer responsibilities:

• Data lake provisioning: Customer provides data lake storage. Customer is responsible for setting correct storage permissions and configuring correct credentials for data lake access in Cumulocity DataHub. Refer to Permissions for data lake and space for more information. We recommend provisioning the data lake in the same hyperscaler and hyperscaler region as Customer’s Cumulocity tenants for the best performance.
• Storage cost: Customer is responsible for managing data retention policies within Customer’s configured S3 bucket or Azure Data Lake Storage and ensuring that offloading jobs are configured appropriately to align with Customer’s organizational requirements, data management strategies and budgets.
• Offloading configuration: Customer maintains compatibility of offloading configurations with the actual data structures present in the operational store. For more information, please see Section “Aligning data modeling and offloading” and Section “Dealing with mixed types”.
• Offloading monitoring: To avoid data loss, Customer is recommended to monitor and respond to offloading alarms as data loss may occur. For example, if the data structures in the operational store change, offloaders configured to “stop pipeline” will halt. If the offloaders are not reconfigured before the configured retention intervals in the operational store apply, data may be deleted before it is offloaded. For this reason, Customer is advised to configure suitable retention intervals in the operational store to allow for reaction times. Alarms can be, for example, forwarded to email for better visibility.
• Data lake modifications: Customer is responsible for Customer’s modifications to the data lake, such as moving or deleting files, as outlined in Section “Modifying data in the data lake”. In particular, moving files may break DataHub offloading jobs.
• Data lake schema: Customer maintains compatibility of the data lake schema with tools querying the data lake.
• Security: Customer is responsible for selecting strong passwords for Dremio access and maintaining the passwords safely. Customer is advised to create Dremio users solely through the Cumulocity DataHub to prevent data leaks between tenants.
• Driver usage: For JDBC and ODBC usage, Customer is advised to download drivers using the links in the documentation.

Limitations and constraints

Customer acknowledges the following limitations and constraints in using Service.

• Service quotas: Customer acknowledges the existence of additional quotas as detailed in service quotas and in the Dremio documentation
• Dremio usage: Customer acknowledges that inside Cumulocity DataHub, not all features of Dremio are available for use. In particular, public cloud instances do not currently support the use of Dremio reflections and additional data sources beyond the Cumulocity operational store.
• Query performance: No response time guarantee can be given for queries, as they can be of arbitrary complexity and are scheduled for execution on shared resources. Overly long-running or resource-consuming queries may be canceled by Cumulocity’s capacity management.

Service availability

Cumulocity is committed to providing reliable service. The specific service availability targets for Cumulocity DataHub are as follows:

• Production environments: 99.00% availability
• Preproduction environments: 95.00% availability

Service availability for Cumulocity DataHub APIs is calculated as outlined in the platform’s service availability section.

Offloading jobs may not run at a scheduled time if a previous offloading job is still in progress (for example, due to an initial larger volume upload or after a longer period of inactivity) or during scheduled maintenance. Subsequent offloading jobs will eventually catch up with remaining data.

Support and maintenance

Support and maintenance are provided as outlined in the platform service-level agreement.

Support can answer questions about schema evolution and schema compatibility mechanisms in DataHub. However, support can generally not assist with troubleshooting Customer’s specific data schemas.

Support service-level agreement

This agreement is made between Cumulocity (“Provider”) and the Customer (“Customer”) who wishes to use support services for Cumulocity.

Service description

This document outlines the maintenance and support services provided for different levels of support: Bronze (“Starter”), Silver (“Standard”) and Gold (“Enterprise Active”).

Definitions

The following terms apply across all support levels unless otherwise specified:

• Business Day: Monday to Friday, excluding public holidays, in the country specified in the Customer address field of the Cloud Services order form, corresponding with Provider’s Support operating days.
• Business Hour: 8:00 AM to 5:00 PM on a Business Day of the main support hub within the Customer’s region. Support operating hours may change from time to time.
  • EMEA: Central European Time (CET).
  • APJ: Malaysia Time (MYT).
  • US: Mountain Time (MT).
• Cloud Services: Provider’s Cloud Services as specified in the Cloud Services order form.
• Error: Any verifiable and reproducible failure of the Cloud Services to substantially conform to the specifications for such Cloud Services. Notwithstanding the foregoing, Error shall not include any such failure that is caused by:
  1. the use or operation of the Cloud Services with any other software or code or in an environment other than that intended or recommended in this documentation,
  2. modifications to the Cloud Services not made or approved by the Provider in writing, or
  3. any bug, defect, or error in third-party software used with the Cloud Services.
• Error Correction: A modification, addition, or deletion that brings the Cloud Services into substantial conformance with specifications or reduces the adverse effect of the Error. It may include a workaround, service update, or solution provided by the Provider.
• Authorized Technical Contact (ATC): An uniquely identified individual authorized by the Customer to access the Provider’s Support Portal, submit support requests, and receive support-related communications, with appropriate professional and technical qualifications. Shared group accounts are not allowed.
• Support: The Provider’s global support Organization responsible for delivering maintenance and support services to the Customer.
• Support Portal: The Provider’s web-based support system that provides access to information, documentation and Error Corrections, and permits browsing and submitting incidents.

Incident classification

Support will classify incidents into three levels of severity according to the following table:

• Crisis Incidents: Customer’s problem has a severe business impact, such as production down. Customer is unable to use the Cloud Services, resulting in a major impact on Customer’s operations. Work cannot reasonably continue.
• Critical Incidents: Customer’s problem has a significant business impact; however, operations can continue in a restricted fashion. The Cloud Services are usable but severely limited. There is no acceptable workaround available. Customer is experiencing a significant loss of service.
• Standard Incidents: Customer’s problem has some business impact. The Cloud Services are usable and cause only minor inconvenience. It may be a minor Error, documentation Error, or incorrect operation of the Cloud Services, which does not significantly impede the operation of the Cloud Service.

Support services

The services provided vary by support level as highlighted in the following table:

* During Business Hours.

The services are defined as follows:

• Phone support: The support telephone number is available in Support Portal. Telephone support is provided in English only.
• Initial response times: Customer will receive an initial response within the defined initial response times.
• Number of ATCs: Restrictions to the number of ATCs apply per Customer, not per contract. Customer may contract for additional ATCs.
• Support region: The region of a customer is the region where that customer is located or has opted to define that region as their region. For example the region for an EMEA customer is EMEA, however an EMEA customer may opt for another region, say APJ, to be their default region. For Gold support, the region can be chosen per ATC.
• Prioritized queuing: Incidents are prioritized ahead of other support incidents of the same severity level but lower support level.

Processing customer requests

General support processing

The following conditions apply to all support levels:

• Customer requests will be received by Support and will be documented in Support Portal for further processing. The Customer will be given a reference processing number for future reference.
• When reaching Support by telephone, Customer is to provide the incident/ticket number so that work on the incident can commence.
• Support has no obligation to solve the Customer’s issue within the response or any other time frame.

Additional Silver support processing

The following conditions apply to Silver level support:

• Critical Incidents will be reported daily unless otherwise agreed with Support on a case-by-case basis. Other incidents will be reported as agreed between Support and Customer on a case-by-case basis.
• Customer is provided with a timeline for Error Correction.

Additional Gold support processing

The following conditions apply to Gold level support:

• On non-Business Days Customer must always report critical and standard incidents through Support Portal and must follow up with Support service provider via telephone in order to receive an initial response from Support based on the agreed upon reaction time. The response time is measured from the time the Customer gets in contact with a Support Engineer.
• Reporting is carried out as agreed between Support and Customer.
• For Crisis Incidents, economically justifiable effort within standard scope of resources is applied. For other incidents, reasonable effort within standard scope of resources is applied.
• For Crisis Incidents, a resolution plan provided within first four (4) hours after receipt of Crisis incident to include - in Provider’s sole discretion - either:
  • a definition of the intended solution to the problem, or
  • a definition of a work-around while Provider develops or defines a solution, or
  • a documented action plan that will include:
    • current status of the resolution
    • target timeline for next feedback
    • responsible Provider resource(s)
    • Customer obligations (for example, provisioning of log files)
• For other incidents, Customer is provided with a timeline for Error Correction.

Customer responsibilities

• Customer assigns Authorized Technical Contacts (ATCs) and communicates any changes to the list of ATCs to Provider.
• Customer’s ATC is responsible for cooperating with Provider’s Support and providing necessary information to reproduce, troubleshoot and resolve the experienced error.
• When an incident is submitted by an ATC to Provider’s Support Portal, Customer authorizes Provider, for the purposes of troubleshooting and resolving such incident, to access Customer’s cloud environment for the duration of the submitted incident.